Kiosk device management in quick service restaurant environments

ABSTRACT

A kiosk system which is capable of maintaining kiosk devices online without physical manipulation is disclosed. The kiosk system is capable of forcing a programmatic re-initialization of kiosk devices when necessary. Individual devices in the kiosk system can be initialized and re-initialized in parallel with normal operation of the kiosk system.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of application Ser. No.12/391,140 filed Feb. 23, 2009 which is hereby incorporated by referencein its entirety.

BACKGROUND Technological Field

This application relates to customer-operated kiosks in quick servicerestaurant environments. In particular, this application relates tosystems and methods for providing kiosk device management for kioskdevices connected to such kiosks.

Description of Related Technology

Existing customer-operated kiosk systems typically integrate variousperipheral devices in order to provide customer ordering services in aquick service restaurant environment. In many cases, these devices maybe encapsulated within the interior of the kiosk device and hidden fromexternal view resulting in difficulty in detecting and correctingproblems. Because failure of certain internal device components maycause the kiosk system to fail or otherwise adversely impact customerexperience, improved kiosk systems are needed.

SUMMARY OF CERTAIN INVENTIVE ASPECTS

The system, method, and devices of the invention each have severalaspects, no single one of which is solely responsible for its desirableattributes. Without limiting the scope of this invention, several of itsfeatures will now be discussed briefly.

In one aspect, there is a kiosk device management system. The kioskdevice management system includes a device discovery module configuredto discover a kiosk device connected to a kiosk computer and report thediscovered kiosk device. The system also include an event bus configuredto receive a notification related to the discovered kiosk device fromthe device discovery module. A model registry is configured to receiveinformation indicative of the discovered device from the event bus andgenerate a device model based on the received information. The systemalso includes a device management module configured to receive statuscodes from the discovered device and send a command to the discovereddevice based on the received status code.

In another aspect, there is a method of managing kiosk devices in akiosk system. The method includes discovering a plurality of kioskdevices connected to a kiosk computer and reporting information relatedto each of the plurality discovered devices to an event bus. The eventbus then transmits the information related to each of the plurality ofdiscovered devices to a model registry. A plurality of device models isgenerated which corresponds to each of the plurality of discovereddevices based at least in part on the information related to each of theplurality of discovered devices.

In yet another aspect, there is a method of providing device managementservices in a kiosk system. The kiosk system has a kiosk applicationthat provides a customer-operated quick service restaurant orderinginterface. The method includes receiving a first device status code in amodel registry of the kiosk system, the device status code comprisingdata indicative of a kiosk device failure condition. The method furtherincludes storing the first status code as current status data for adevice model corresponding to the kiosk device in the failure conditionand issuing a command for the kiosk application to enter a lowerfunction mode based at least in part on the first status code. Lastly,the method includes generating a re-initialization command for thefailing kiosk device; and transmitting the re-initialization command tothe failing kiosk device.

BRIEF DESCRIPTION OF THE DRAWINGS

In this description, reference is made to the drawings wherein likeparts are designated with like numerals throughout.

FIG. 1 is an example of a customer-operated kiosk device suitable forimplementation of one or more embodiments disclosed herein.

FIG. 2 is a block diagram illustrating one example of a kiosk devicemanagement system implemented within the kiosk shown in FIG. 1.

FIG. 3 is a more detailed view of the device discovery and managementmodule shown in FIG. 2.

FIG. 4 is a more detailed view of the event bus shown in FIG. 2.

FIG. 5 is a more detailed view of the model registry shown in FIG. 2.

FIG. 6 is a more detailed view of a device model shown in FIG. 2.

FIG. 7 is a flowchart illustrating a process by which devices arediscovered and registered in the kiosk in accordance with one or moreembodiments.

FIG. 8 is a flowchart illustrating a process by which the kioskapplication may modify its operations based on messages received fromthe model registry.

FIG. 9 is a flowchart of a process by which the kiosk device managementsystem may infer the meaning of unknown status codes from a peripheraldevice in the kiosk.

FIG. 10 is a flowchart of a process by which a kiosk may enter a lowerfunction mode of operation based on information generated by the modelregistry.

FIG. 11 is a flowchart of a re-initialization process in accordance withone or more embodiments.

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS

Various embodiments disclosed herein relate to systems and methods forproviding autonomic device management for customer-operated orderingkiosks which are operated in quick service restaurant environments.

Issues of reliability and performance have prevented wide-scale adoptionof customer-operated ordering kiosks in quick service restaurant (QSR)environments. The QSR environment is fast-paced, and the large majorityof customers and therefore revenues are serviced during a few peakmealtime hours each day. The customer-operating ordering kiosksinstalled in QSR environments typically include internal softwarerunning on a computer. The computer, in turn, may be connected to otherkiosk devices such as computer peripheral devices, for example whichprovide services to the kiosk application. For example, the kioskcomputer may be connected to a printer which is used to print customerreceipts from the ordering kiosk.

Although peripheral devices in the kiosk are often important to theoptimal operation of the kiosk, they are not in some cases absolutelynecessary for the kiosk to operate. Nevertheless, failure of a kioskdevice during a peak mealtime such as during the lunch hour, can have asignificant effect on the profitability for a particular day. Existingkiosk devices have been problematic because they have commonlyencountered problems which require system maintenance during the timesthat they are most heavily used. These problems have included untimelyfailure of kiosk devices such as receipt printers, credit cardprocessing, cash handling, and the like. Additionally, because kioskdevices are typically located in a secured interior portion of thekiosk, and are often placed in environments which allow limited hours ofserviceability, when a kiosk device fails it is difficult to remedy thefailure for several hours due to these issues of security, location,error detection, or interruption of customer experience.

The inventors have also recognized that existing QSR kiosk solutionshave also suffered from offering inflexible software support for thevariety of kiosk devices that may be installed or operated within thekiosks. Kiosk devices used within the kiosks are often specialized innature, and therefore, may be manufactured in relatively small batches.When kiosk devices fail, they may need to be replaced by new kioskdevices. Manufacturing kiosk devices in small batches can lead to smallvariances in physical hardware attributes as well as subtle differencesin device firmware which may manifest during certain error scenarios. Asa result, the behavior of a replacement device and its device specificerror codes may not always be fully known before the replacement deviceis sent into the field.

Kiosk systems in the field, particularly when unmanned, may be subjectedto abusive behavior such as jarring, blocking of printer output areas,and accidental static discharge which can temporality render the printerand other kiosk devices unavailable for a small number of transactions.These situations may resolve themselves naturally within minutes (oreven seconds), but in ordinary circumstances, the kiosk applicationrunning on the kiosk computer may not be aware that the situation hasbeen resolved and thus may not resume its normal interface andcommunication with the kiosk device. Thus, a re-initialization of thekiosk system may be required to restore full functionality. Becauseinitialization of the kiosk system may involve starting andinitialization many kiosk devices, a re-initialization can take severalminutes to complete.

In order to address the operating challenges described above, theinventors have developed a kiosk system which is capable of maintainingkiosk devices online without physical manipulation, and is furthercapable of forcing a programmatic re-initialization of kiosk deviceswhen necessary. Moreover, because complete initialization of a kiosksystem is such a time consuming event, the inventors have developed akiosk system in which individual devices can be initialized andre-initialized in parallel with normal operation of the kiosk system.

Turning now to FIG. 1, an example of a kiosk 100 is provided. Theexample provided in FIG. 1 is a plan view of the exterior of the kiosk100. The kiosk 100 includes a kiosk door 102. The kiosk door 102 may beattached to a kiosk body 104 by hinges or some other connectingmechanism. The kiosk door 102 may be opened to expose the interiorcabinet of the kiosk 100. The kiosk door 102 may be secured by a lockingmechanism to prevent access to the interior cabinet of the kiosk 100 byunauthorized individuals. The kiosk body 104 together with the kioskdoor 102 may cooperatively form a hollow enclosure which is typicallyreferred to as the kiosk cabinet or kiosk housing. Many of the kioskdevices which provide services to the kiosk application are locatedwithin the kiosk cabinet or housing.

The kiosk door 102 may have cutout areas forming apertures through whichlimited access may be provided to internal kiosk device components. Forexample, one aperture in the kiosk door may provide access to a kioskdisplay 106. The kiosk display 106 may be a touch screen display thatmay be used by the customer to operate a kiosk software application. Thekiosk software application may be stored in a memory on a kiosk computer(not shown) which is positioned in the kiosk cabinet and generally notaccessible without first opening the kiosk door 102. Another aperture inthe kiosk door 102 may provide access to a bill accepting device 108.The bill accepting device 108 may be used to receive payments in theform of cash or some other paper currency or note for services rendered.The bill accepting device 108 may form a part of a larger cash handlingsubsystem which also includes a cash dispenser 110 and a coin dispenser112. As shown in FIG. 1, certain portions of the cash dispenser 110 andthe coin dispenser 112 are made accessible to the customer viaadditional apertures formed in the kiosk door.

Because the kiosk 100 is configured to conduct business transactions,the kiosk 100 may be configured with a printing device 114. The printingdevice 114 may be a specialized receipt printer which is connected tothe kiosk computer and which prints receipts to customers in accordancewith kiosk application requirements. The receipt printing device may bepositioned predominantly within the kiosk cabinet as shown, with onlythe paper output area protruding through an aperture formed in theexterior of the kiosk 100. Also part of the payment subsystem in thekiosk may be a credit card processing device 116. In the example shownin Figure, a portion of the credit card processing device 116 extendsthrough an aperture to receive a credit card (or other type of card)swipe from the customer.

All of the devices described above merely illustrate some of the kioskdevices which may be located within the interior portion of the kiosk100. As a skilled artisan will readily appreciate, the kiosk 100 mayinclude many other different kiosk devices and may be configured invarious other ways. For example, the kiosk door may be located on theback side of the kiosk 100 instead of the front side, and the aperturesmay be formed within the kiosk body 104 instead of within the kiosk door102. Further, the relative locations of the various kiosk devices neednot necessarily be provide as shown in FIG. 1, and the example providedthere is merely illustrative of one possible kiosk suitable forimplementation of the device management techniques disclosed herein.

As discussed above, the kiosk 100 may be use a computing device orcomputer which is connected to various other kiosk devices to performthe ordering functions assigned to the kiosk 100. The computing devicemay be a specialized computer which is designed specifically for kioskoperations, or in some embodiments, the computer may be a standardpersonal computer device such as an Intel processor-based PC running anoff the shelf operating system such as Windows, Linux, MacOS, or thelike. As used herein, the term “computing device” or “kiosk computer”generally refers to one or more computers which are connected to kioskdevices to control the operation of kiosk. The term “kiosk system”refers to both the computing device and the kiosk devices that areconnected to it. The kiosk devices may be computer peripheral devicessuch as the kiosk printer 114, the kiosk display 106, the kiosk billcollector 108, the bill dispenser 110, the coin dispenser 112, or othertypes kiosk devices. A “kiosk application” refers to one or moresoftware applications executing on the kiosk computer which provide theuser interface for the kiosk and its other operations.

FIG. 2 is a block diagram illustrating one example of the logicalcomponents of a kiosk device management system 200 that may beimplemented within the kiosk system discussed above. The kiosk devicemanagement system 200 generally includes hardware and software whichenables the kiosk system to address device failures in such a way as tominimize the impact on the customer's experience. As shown in thefigure, there are various kiosk devices 202A, 202B, and 202C which maybe managed by the device management system 200 and are accessed by thekiosk device management system 200 via one or more device drivers 203A,203B, and 203C which may be installed in the operating system of thekiosk computer. In one embodiment, the kiosk device 202A may be areceipt printer, device 202B may be a credit card processor, and 202Cmay be a cash handling device. In addition, a kiosk application 220 alsomay be present and communicating with the kiosk device management system200. The kiosk application 220 may communicate with the kiosk devicemanagement system 200 by sending and receiving messages from an eventbus 204. Although the kiosk application is shown as existing outside ofthe kiosk device management system 200, a skilled artisan shouldappreciate that the kiosk application 220 may run on the same kioskcomputer as the kiosk device management system 200. Moreover, is someembodiments, the kiosk device management system may actually be asubcomponent of the kiosk application 220.

As noted above, the kiosk device management system 200 may include anevent bus 204. The event bus 204, which may take the form of a softwaremodule or service, typically receives and delivers messages to othercomponents in the kiosk device management system 200. As part of thekiosk device management system 200, the event bus is typically used toreliably transmit information about the existence or health of kioskdevices 202 to other subsystems in the kiosk device management system200 or to the kiosk application 220. In one embodiment, the event busoperates according to a publish and subscribe model which providesasynchronous messaging services. Additional details about the event bus204 are discussed below in connection with FIG. 4.

The kiosk device management system 200 may also include a devicediscovery and management module 206. The device discovery and managementmodule 206 typically takes the form of a software service and performstwo general functions: device discovery and device management. Althoughthe embodiment described in FIG. 2 shows both of these functions asbeing integrated into a single module, a skilled artisan will appreciatethat the two functions may also be provided by two separate modules, onedirected to device discovery and the other directed to devicemanagement. Discovered devices may be managed by the device managementmodule. The device management module may receive remote procedure callsfrom the event bus 204 (which may be originated in the kiosk application220) and routes them to the attached devices.

With respect to device discovery, the software service may be configuredto discover kiosk devices which are attached to the kiosk computer, orare otherwise part of the kiosk system. Typically, these kiosk devicesare attached via a direct hardware interface such as a printer port onthe kiosk computer, a USB port, an RS232 interface, and IP networkinterface (wired or wireless), or some other type of connection. In someembodiments, the discovery of the kiosk devices may be achieved usingvarious device discovery techniques. For example, the device discoverymodule may be configured to read a configuration file stored in a memoryof the kiosk computer which contains information about connecteddevices, including information related to prioritization of resources.The device discovery module may also be configured to scan known devicelocations in the operating system of the kiosk computer to determinewhich kiosk devices are connected to the kiosk computer and workingproperly. These known device locations may include certain ports (bothphysical and virtual), or these location may also include registryinformation which is indicative of the status of the ports. For kioskdevices which are available to the kiosk computer via a networkconnection, the discovery module may be configured to access simplenetwork management protocol (SNMP) information to discovernetwork-connected kiosk devices. In addition, the discovery module mayaccess Universal Plug and Play (UPnP) information from the kioskcomputer which provides additional details about connected devices.Other methods of kiosk device discovery may be used such as javamessaging services (JMS) for example.

Once the discovery module 206 discovers kiosk devices, it is typicallyconfigured to report the discovered device to the event bus 204. Theevent bus 204, in turn, may pass the device discovery message to themodel registry 208. The model registry 208 is a software component ormodule which is configured to create and manage device models 210.Device models 210 are abstractions of the physical devices 202 which arediscovered by the discovery and management module 206 and will bediscussed in greater detail below. The model registry 208 receivesinformation from the event bus 204 and generates a “best-fit” devicemodel 210 for the physical device 202 using existing property comparisonalgorithms. The property comparison algorithms typically allow the kiosksystem to select non-optimal kiosk devices to carry out certainrequests. For example, a kiosk application may request a printer whichis capable of printing in color, and landscape layout. The modelregistry would then iterate through its discovered devices and find ifany are capable of performing such print jobs. If none exists, it mayloosen its requirements and query for a less capable, but stillacceptable device. Other property comparison algorithms may be used in asituation whether the kiosk requests a printer capable of printingreceipts (in the standard format). If one is unavailable, the algorithmsmay allow the kiosk to settle for a standard laser printer which is alsoattached to the kiosk. As shown in FIG. 2, the model registry 208 maygenerate a device model (210A, 210B, 210C) which corresponds to eachphysical device (202A, 202B, 202C) discovered by the device discoveryand management module 204.

As noted briefly above, the device models 210 are software modules orcomponents which abstract certain details about the physical device 202to which they correspond. These abstracted details may include theserial number of the device 202, the device manufacturer, the devicemodel, capabilities of the device, or some other information. Theabstracted information is made available to the kiosk application 220 sothat the device may be accessed by the kiosk application 220 in ageneric manner without needing low level device programming incorporatedinto the kiosk application logic.

The kiosk device management system 200 shown in FIG. 2 generallyoperates continuously while the kiosk system is active. As will bedescribed in more detail below in connection with FIGS. 7-12, the devicediscovery and management module 204 may be configured to regularly checkthe kiosk system for new devices and may be further configured tomonitor the discovered devices for the status codes and messages via thedevice driver 203 associated with each respective physical device 202.The status codes are reported across the event bus 204, where they arepicked up by the model registry and incorporated into the appropriatemodel. If inactivity in a device 202 is detected by the managementmodule 206, or if a known error code is encountered, the managementmodule may be configured to send a re-initialization command to thedevice 202.

FIG. 3 is a more detailed view of the device discovery and managementmodule 206 shown in FIG. 2. As shown, the discovery and managementmodule 206 may include various sub-modules and/or subcomponents. Thediscovery and management module 206 may contain a discovery sub-module302. The discovery sub-module 302 typically comprises one or morefunctions, methods, or even classes which may be used to identify thephysical devices 202 which are connected to the kiosk computer andtherefore part of the kiosk system. As noted above, the kiosk devicemanagement system 200 may be configured to continuously monitor thekiosk system for new kiosk devices.

Also included in the device discovery and management module 206 is aninitialization sub-module 304. The initialization sub-module 304incorporated into the discovery and management module 206 typicallyincludes initialization commands for the devices that have beendiscovered by the discovery sub-module 302. The initializationsub-module 306 is typically used in two circumstances. First, theinitialization logic is called for the purpose of sending initializationcommands to kiosk devices during the startup process of the kiosksystem. Second, the initialization logic may also be used to attempt tore-initialization devices which have become inactive or have reportederror conditions which require a restart of the device.

The device discovery and management module 206 also includes amanagement sub-module 308. The management sub-module 308 includesfunctions and methods which may query discovered devices 202 via theirassociated device driver 203 for the current status of the device 202.The management logic may also receive messages/command from the eventbus 204 which are intended for a device and send those messages/commandsto the device via the device driver. For example, in one embodiment, ifthe kiosk application makes a print request to a printer device modelsuch as device model 210A, the model registry 208 passes that printrequest to the event bus 204 which in turn delivers to message to thedevice management module 206. Alternatively, the kiosks requests may beissued directly to the device model 210 and then sent directly to thedevice management module 206, or even the device subsystem the modelrepresents. The device management module 206 then converts the commandinto the machine-understandable print code and sends the code to theappropriate driver 203A. The device driver 203A may then pass the codeto the printing device 202A which then executes the print command in theprinting hardware.

FIG. 4 is a more detailed view of the event bus 204 shown in FIG. 2. Asnoted previously, the event bus 204 may take the form of a publish andsubscribe model event bus. In the embodiments shown in FIG. 4, the eventbus 204 includes one or more event sources 402 and event subscribers404. The event sources 402 may take the form of a table of subsystems inthe kiosk device management system 200 known to pass messages to theevent bus. The event sources may serve as publishers in publish andsubscribe models. The event subscribers 404 include devices, components,processes, and models which have subscribed for event notifications fromthe event bus. The event bus may also include various message receiptand delivery functions 406 which handle the actual message passing bythe event bus.

Turning now to FIG. 5, a more detailed view of the model registry isprovided. As shown, the model registry may include a model generator502. The model generator 502 receives information from the event bus 204and generates device models 210 based on the received information. Themodel registry 208 may also include one or more property comparisonalgorithms which may be used by the model generator 502 to generate adevice model 210 which accurately reflects (and abstracts) thecapabilities of the device 202 being modeled. As noted previously,property comparison algorithms property comparisons may compare thekiosk requested properties/capabilities of the kiosk device with theactual properties/capabilities of the device to find a best match. Themodel registry 208 may further include status code data 506. The statuscode data 506 may take the form of a table of known status codes fordevices that have been discovered in the kiosk system. The status codedata may be used by the model registry to interpret codes enclosed inmessages received from the event bus 204. In some instances, unknowncodes may be received by the model registry. These codes may also bestored in the status code data 506 and later interpreted based ontesting and other information provided by the device model 210associated with the unknown codes.

In certain embodiments, the model registry 208 may be configured tostore a list of discovered models and organize them into general devicetypes (such as bill acceptor, printer, for example). The device models210 may also model external systems, such as point of sale systems, orexternal credit card processors, for example.

When the model registry receives a status message, it compares themessage source to its existing device models 210, and if there is a newdevice reporting, the model generator 502 may generate a new model fordevice sending the message, based on the information the device hasgiven. In some embodiments, the capabilities of a device may be listedin a separate repository instead of being directly reported by thedevice to the event bus 204. For example, a device may simply reportthat it is a SWECOIN 2030 device. From that reporting message, anotherrepository of information may be accessed to determine that device is aprinter with 300 dpi, black and white toner and a 3 cm paper roll.

FIG. 6 is a more detailed view of the device model 210 shown in FIG. 2.As discussed above, a device model 210 is an abstraction of a physicaldevice 202 generated by the model registry 208 which has been previouslydiscovered by the device discovery and management module 206. The kioskapplication 220 communicates with peripheral devices as that abstractedlevel which allows the kiosk application to be shielded from needing toknow or understand low level details about the device hardware. Eachdevice model 210 may include specific information about the underlyinghardware device 202. In one embodiment, the device model 210 includesdevice identifying information 602. The device identifying information602 may include information such as the device model, the devicemanufacturer, the device firmware version (if known), the device driverversion, and other information which may be used to identify thespecific device.

The device model 210 may also include device status data 604. The devicestatus data 604 may take the form of a status code which has beenreceived from the event bus 204 via the device discovery and managementmodule 206. Typically, the device status data include the code mostrecently received from the event bus 204. In some implementations,historical device code data may be stored with the device model 210. Thedevice model 210 may further include device command data 606. The devicecommand data 606 may include command codes which may be sent to theunderlying physical device 202 associated with the device model 210 viathe event bus 204, directly, or via the device management module 206 inorder to allow the kiosk application 220 to control the physicalhardware device.

FIGS. 7-11 below are flowcharts which describe the various processesperformed by the components in kiosk device management system 200. FIG.7 is a flowchart illustrating a general process by which devices areinitially discovered and registered in the kiosk in accordance with oneor more embodiments.

The process begins at block 702, where the kiosk application 220 beginsthe boot up process. As noted above, the kiosk application is typicallystored in a memory of the kiosk computer and is executed by a processorlocated in the kiosk computer. The kiosk application boot up processtypically occurs when the kiosk is “turned on” so that it can be used inthe field by customers. As part of the boot up process, the operatingsystem on the kiosk computer loads into memory, and the kioskapplication 220 begins execution.

Next, at block 704, the kiosk application 220 has been loaded intomemory and the discovery sub-module 302 of the device discovery andmanagement module 206 is called. At block 706, the discovery sub-modulediscovers (possibly using the loaded device drivers 203) the physicalkiosk devices 202 which are operating within the kiosk system. As notedabove, the device discovery sub-module may be configured to scan knowndevice locations such as physical and virtual ports in the operatingsystem of the kiosk computer to determine which kiosk devices areconnected to the kiosk computer and working properly. The devicediscovery sub-module may also use a management protocol such as SNMP andUPnP, or some proprietary device discovery method to discover attachedkiosk devices. The process then optionally moves to block 708 where theinitialization sub-module 304 of the device discovery and managementmodule 206 sends device initialization commands to the devices that ithas discovered. This block is denoted as optional because, in someinstances, the operating system of the computer may have also alreadyinitialized the devices making initialization commands unnecessary.

The process next moves to block 710 where the discovered deviceinformation is transmitted by the device discovery and management module206 to the event bus 204 for processing. The event bus 204 receives thedevice information and then transmits it to the model registry 208 atblock 712. The process then moves to block 714, where the model registry208 creates a device model 210 based on the device information receivedfrom the event bus 204. As discussed above, the device model 210generated by the model registry 208 is an abstracted representation ofthe physical device 202.

When the device models have been generated using the process of FIG. 7,the kiosk application 220 may then access the model registry 208 inorder to access kiosk device services. As noted previously, theabstraction of the physical devices 202 into device models 210 allowsfor considerable flexibility in terms of how the kiosk application 220interacts with the kiosk devices connected to the kiosk computer. Themodel registry 208 allows the kiosk application 220 to specify servicesthat it needs, and the model registry 208 attempts to match the devicemodel 210 which is capable of providing the requested service. If theoptimal or “best” device for carrying out the request is not available,the model registry 208 may consider other device models 210 which may beable to carry out the kiosk application request. For example, if theprimary receipt printer 114 in the kiosk has an error code statusassociated with it in the model registry, a secondary printing device,such as a printer available over the network, may be selected by thedevice registry 208.

FIG. 8 is a flowchart illustrating a process by which the model registry208 is able to allocate a kiosk application 220 request to a secondarykiosk device. The process begins at block 802 where the kioskapplication 220 executes a process which needs a particular service suchas printing a receipt, for example. The process then moves to block 804,where the kiosk application generates a request for device services.This request for device services typically includes the type of serviceand any data that is associated with that service. For example in thecase of printing a receipt, the kiosk application may send a “print”request to the event bus 204 along with the name of a file to beprinted.

The process then moves to block 806, where the generated request ispassed to the model registry 208. The model registry 208 receives themessage from the event bus 204 and searches for a device model which hasthe requested properties at block 808. For example, if the kioskapplication has requested the printing service, the model registrysearches each device model in the registry to identify those devicescapable of carrying out the request.

The process then moves to decision block 810, where it is determinedwhether an appropriate model 210 has been found in the model registry208. If a device model 210 suitable for carrying out the kioskapplication request is identified, then the process moves to block 814where the device model 210 is selected and the kiosk application requestis sent to the selected device model 210. If, at decision block 810, anappropriate model is not found, the process instead moves to block 812,where the closest matching device model is selected to carry out thekiosk application request.

For example, if the local printer in the kiosk system is unable to carryout the request, for instance, due to it being out of paper, the modelregistry 208 may have a secondary network printer that may be capable ofcarrying out the request. However, the network printer may not have thepaper size specified by the print request. Even though the paper size isnot optimal, the print request may be sent to the secondary printer todetermine whether the print job can be successful or not.

In some embodiments, it is also possible to find that there is not aclosely matching device model. In this instance, the kiosk applicationmay be notified that no such device exists, and may then modify itsprocess to work around the deficiency. Alternatively, the kioskapplication may also simply go offline if the request cannot befulfilled by any device model.

As noted above, one of the challenges facing effective kioskimplementation in a QSR environment is the fact that kiosk devices areoften manufactured in small batches by various vendors resulting inslightly different configurations of kiosk devices over time. Theseslightly different configurations may include different firmwareversions, for example. The different firmware versions might haveslightly different device codes. Thus, when a particular model of akiosk device is replaced with a newer version of the same model, thecodes received by the model registry 208 from the device managementsub-module may not be the codes that are expected for that type ofdevice. In existing systems, these types of inconsistencies cause thekiosk device to raise an exception, and may cause the device to beunusable until the codes are updated. In some embodiments, the kioskdevice management system 200 may include a learning component thatallows it to handle situations such as these by inferring meaning ofunknown codes based on defined behavior associated with those codes.

FIG. 9 is a flowchart of a process by which the device management system200 may infer the meaning of unknown status codes from a peripheraldevice in the kiosk 100. The process begins at block 902, where thedevice management component 302 of the device discovery and managementmodule 206 obtains a status code from a kiosk device 202 and sends thestatus code to the event bus 204. Next, at block 904, the event bus 204passes the status code to the model registry 208. At decision block 906,the model registry receives the status code and determines whether thecode is a known code for that device model 210. If the code is known,the system operates normally and the status code is interpretedaccording to the data in the device model 210 and the status of thedevice model 210 is updated accordingly with the new status code.

If at decision block 906 the status code is not known or present in thedevice model 210, the model registry first updates the device model 210with the new status code at block 908. The process next moves to block910 where it tests the device. Once the device has been tested, thestatus code is then interpreted based on the result of the test at block912. By way of example and not of limitation, if the device model 210 isfor a printer, and the new status code is not recognized by the deviceregistry, a test print may be sent to the printing device to determinewhether it is operating properly. If the test print is successful, thestatus code may be then interpreted or inferred to mean that the printerdevice is functioning properly. In some embodiments, if the status codecannot be interpreted, the device may be set as being in an “UNKNOWN”status can be considered offline and unavailable to process requests.

In some embodiments, the kiosk device management system 200 may also beused to allow the kiosk to enter a lower function mode if certain kioskdevices are unavailable to prevent a negative impact on the customerordering experience. FIG. 10 is a flowchart of a process by which akiosk may enter a lower function mode of operation based on informationgenerated by the model registry.

The process begins at block 1002 where a kiosk device 202 generates adevice status code. The process then moves to block 1004, where thedevice status code for the kiosk device 202 is received by the modelregistry 208. As discussed above, the status code may be obtained fromthe kiosk device 202 by regularly polling the device 202 with themanagement sub-module 308 of the device discovery and management model206. The result received by the management sub-module is then sent tothe event bus 204 which it turns passes the data to the model registry208.

Next, at block 1006, the status code obtained from the device 202 isstored in the status data 604 of the device model 210 that is associatedwith the device 202. The process then moves to decision block 1008,where the model registry 208 determines whether the device status 604requires a change in the operating mode of the kiosk application. If nochange in kiosk operating mode is required at block 1008, then theprocess moves to block 1014 and the kiosk remains in its currentoperating mode. The process then loops back to block 1002 and repeats.

If at decision block 1008 a change in the operating mode of the kiosk isrequired, the process moves instead to block 1010, where a new kioskoperating mode is determined based on the status data. Once the new modehas been determined, the process then moves to block 1012, where thekiosk enters the selected new operating mode. Once the new operatingmode has been entered by the kiosk, the process loops back to block 1002and begins again.

Thus, the process set forth in FIG. 10 allows the status of the kioskdevices to be continuously monitored by the kiosk device managementsystem 200 and modify the kiosk's operating mode in response to eventsthat occur in the kiosk devices 202. In some embodiments, the status ofeach device 202 is reported asynchronously to the kiosk system via theevent bus 204, and the kiosk application 220 can react accordingly whenit is convenient to do so, for example, at the beginning of atransaction and before a customer is engaged.

In one specific implementation of the process described in FIG. 10, thekiosk device management system may change the operating mode of thekiosk based on a low paper message received from a printer device 214 inthe kiosk system. In some receipt printers, paper is delivered as a rollof paper. Because the size of orders differs from customer to customer,the length of a receipt printed by the kiosk device may be variablebased on the content of the order. Thus, a low paper status code fromthe printing device may not mean that there are a specific number ofreceipts that may be printed due to the variable size of the receipts.Even though the paper in the printer may not be exhausted, it may bedesirable to change the kiosk application into a “no print” mode so thatno customer attempts to print a receipt only to find that there is nopaper available.

Thus, in accordance with the process described in FIG. 10, the printer202 may be initially sending a “normal function” code to the devicemodel 210 representing the printer, and when the kiosk requests a print,the print job is sent by the printer model 210 to the printer device202. However, if the printer becomes low on paper and a low papermessage is sent to the model registry 208, the low paper status maytrigger a change in the kiosk application mode to a “no print” modeprior to the next customer accessing the kiosk application 220. Bychanging the kiosk into a “no print” mode, the risk of an out of papererror occurring during a customer transaction is eliminated. Similarly,if the printer paper is replenished, the process described in FIG. 10will ensure that the kiosk application 220 returns to its normaloperating mode. Such decisions or business rules may be encapsulated indifferent models which can be configured. A single printing device mayhave more than one associated model. A “PrinterModel” may be providedwhich allows “PessimisticPrinterModel” which turns offline at first signof low paper, allowing different customers to configure kiosk behaviorscleanly and quickly.

In still another embodiment, the kiosk application may change its cashhandling mode based on status codes received from the various deviceswhich are used to conduct payment transactions. For example, if thecredit card swipe 116 is in an error condition detected by the modelregistry 208, the kiosk application 220 may be configured to operate ina “cash-only” mode until a device model 210 for the credit cardprocessing device 116 indicates a normal operating condition.

In some additional embodiments, when an error condition is encounteredin one or more kiosk devices 202, the kiosk device management system200, in addition to modify the operating mode of the kiosk application220, may also be configured to attempt to correct the error condition byre-initializing the device in such a way as to not adversely impact thecustomer ordering experience. FIG. 11 is a flowchart of are-initialization process in accordance with one or more embodiments.

The process of FIG. 11 begins at block 1102, where a status code isreceived from a kiosk device 202 at the model registry 208. The receivedstatus code indicates that the device is in an error condition. Themodel registry 208 then stores the status code in the code data 604 ofthe appropriate device model 210 at block 1104, and the device statusfor the device model 210 indicates that the device is inoperative atblock 1106. The process then moves to block 1108, where based on thestatus data 604 for the device model, the kiosk application 220 enters alower function mode such as, for example, a “no-print” mode or“cash-only” mode described above. Next, at block 1110, the kiosk devicemanagement system 200 attempts to correct the error condition bygenerating a re-initialization command for the problem device 202. Inone embodiment, this command may be generated by the model registry 208and passed to the device 202 via the event bus 204, device managementmodule 206, and device driver 203. Alternatively, the command may begenerated by the initialization sub-module 306 of the device discoveryand management module 206. At block 1114, the affected device isre-initialized and sends a status code indicating normal operation.Then, at block 1116, the model registry 208 and device model 210 areupdated to indicate that the device is operating normally. A messageindicating normal operation of the device is then passed via the eventbus 204 to the kiosk application 220. The kiosk application receives themessage and changes its operating mode back to the normal operating modewith respect to the kiosk device 202.

In some embodiments, the process shown in FIG. 11 may be carried outcompletely hidden from the kiosk customer. For example, while a customeris placing a food order using the kiosk, a printer failure message maybe received in the device registry. While the customer continues toplace the order, a background process in the kiosk application may placethe application in a “no-print” mode, while the kiosk device managementsystem 200 carries out the process of FIG. 11. There is no need toreinitialize the entire kiosk application 220, but rather only thespecific device 202 which was affected is re-initialized by the system.

Those of skill will recognize that the various illustrative logicalblocks, modules, circuits, and algorithm steps described in connectionwith the embodiments disclosed herein may be implemented as electronichardware computer software or combinations of both. To clearlyillustrate this interchangeability of hardware and software, variousillustrative components, blocks modules, circuits, and steps have beendescribed above generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular application and design constraints imposed on the overallsystem.

Skilled artisans may implement the described functionality in varyingways for each particular application, but such implementation decisionsshould not be interpreted as causing a departure from the scope of thepresent invention. The various illustrative logical blocks, modules, andcircuits described in connection with the embodiments disclosed hereinmay be implemented or performed with a general purpose processor, adigital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic device, discrete gate or transistor logic, discretehardware components, or any combination thereof designed to perform thefunctions described herein.

A general purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

The steps of a method or algorithm described in connection with theembodiments disclosed herein may be embodied directly in hardware, in asoftware module executed by a processor, or in a combination of the two.A software module may reside in RAM memory, flash memory, ROM memory,EPROM memory, EEPROM memory, registers, hard disk, a removable disk, aCDROM, or any other form of storage medium known in the art. Anexemplary storage medium is coupled to the processor such the processorcan read information from and write information to, the storage medium.In the alternative, the storage medium may be integral to the processor.

The processor and the storage medium may reside in an ASIC. The ASIC mayreside in a user terminal. In the alternative the processor and thestorage medium may reside as discrete components in a user terminal.

While the above detailed description has shown, described, and pointedout novel features of the invention as applied to various embodiments,it will be understood that various omissions, substitutions, and changesin the form and details of the device or process illustrated may be madeby those skilled in the art without departing from the spirit of theinvention. As will be recognized, the presently disclosed embodiment maybe embodied within a form that does not provide all of the features andbenefits set forth herein, as some features may be used or practicedseparately from others. The scope of the invention is indicated by theappended claims rather than by the foregoing description. All changes,which come within the meaning and range of equivalency of the claims areto be embraced within their scope.

What is claimed is:
 1. A method of providing device management servicesin a kiosk system, the kiosk system having a kiosk application thatprovides a customer-operated quick service restaurant orderinginterface, the method comprising: receiving a first device status codein a model registry of the kiosk system via an event bus, the devicestatus code comprising data indicative of a kiosk device failurecondition; storing the first status code as current status data for adevice model corresponding to the kiosk device in the failure condition;issuing a command for the kiosk application to enter a lower functionmode based at least in part on the first status code; generating are-initialization command for the failing kiosk device; and transmittingthe re-initialization command to the failing kiosk device.
 2. The methodof claim 1, further comprising: re-initializing the failing kioskdevice; obtaining a second status code from the re-initialized kioskdevice, the status code indicative of normal device operation; andstoring the second status code as current status data for the devicemodel corresponding to the re-initialized kiosk device.
 3. The method ofclaim 2, further comprising issuing a command for the kiosk applicationto enter another function mode based at least in part on the secondstatus code.
 4. The method of claim 1, wherein the first device statuscode received in the model registry of the kiosk system is sent to themodel registry from a device management module via the event bus.
 5. Themethod of claim 1, wherein the re-initialization command is generated bya device management module in the kiosk system.
 6. The method of claim1, wherein the first device status code is received in the modelregistry asynchronously.
 7. The method of claim 1, wherein the firstdevice status code comprises a low paper status code and the kioskdevice comprises a printing device.
 8. A kiosk device management system,comprising: a device management module configured to generate a firstdevice status code, the device status code comprising data indicative ofa kiosk device failure condition; an event bus configured to receive thefirst device status code from the device management module; and a modelregistry configured to receive the first device status code from theevent bus and store the first status code as current status data for thedevice model corresponding to the kiosk device in the failure condition,wherein the model registry is further configured to: issue a command forthe kiosk application to enter a lower function mode based at least inpart on the first status code; receive a re-initialization command forthe failing kiosk device; and transmit the re-initialization command tothe failing kiosk device.
 9. The system of claim 8, wherein the modelregistry is further configured to: issue a command to re-initialize thefailing kiosk device; obtain a second status code from there-initialized kiosk device, the status code indicative of normal deviceoperation; and store the second status code as current status data forthe device model corresponding to the re-initialized kiosk device. 10.The system of claim 9, wherein the model registry is further configuredto issue a command for the kiosk application to enter another functionmode based at least in part on the second status code.
 11. The system ofclaim 8, wherein the device management module is further configured togenerate the re-initialization command.
 12. The system of claim 8,wherein the model registry is further configured to receive the firstdevice status code asynchronously.
 13. The system of claim 8, whereinthe first device status code comprises a low paper status code and thekiosk device comprises a printing device.
 14. A method of managing akiosk system, the method comprising: identifying a first device that haslimited functionality; attempting, via a device discover module, todiscover a second device that provides at least a portion of thefunctionality typically provided by the first device; switching servicesto the discovered second device if the attempt is successful; andcausing the kiosk to provide a message of notifying a customer of thelimited functionality.
 15. The method of claim 14, further comprising:receiving, via an event bus, a notification related to the discoveredsecond device from the device discovery module; receiving, at a moduleregistry, the information indicative of the discovered second devicefrom the event bus; and generating, at the module registry, a devicemodel based on the received information.
 16. The method of claim 15,further comprising: receiving, at a device management module, statuscodes from the discovered second device, and sending a command to thediscovered second device from the device management module, based on thereceived status code.
 17. A kiosk device management system, comprising:a model registry configured to identifying a first device that haslimited functionality; a device discovery module configured to discovera second device that provides at least a portion of the functionalitytypically provided by the first device; and an event bus configured toreceive a notification related to the discovered second device from thedevice discovery module, wherein the model registry is furtherconfigured to: switch services to the discovered second device if theattempt is successful; and cause the kiosk to provide a message ofnotifying a customer of the limited functionality.
 18. The system ofclaim 17, further comprising: a module registry configured to receivingthe information indicative of the discovered second device from theevent bus, and generate a device model based on the receivedinformation.
 19. The system of claim 18, further comprising: a devicemanagement module configured to receive status codes from the discoveredsecond device, and send a command to the discovered second device basedon the received status code.
 20. A method of providing device managementservices in a kiosk system, the kiosk system having a kiosk applicationthat provides a customer-operated quick service restaurant orderinginterface, the method comprising: receiving a first device status codein a model registry of the kiosk system, the device status codecomprising data indicative of a kiosk device failure condition; storingthe first status code as current status data for a device modelcorresponding to the kiosk device in the failure condition; issuing acommand for the kiosk application to enter a lower function mode basedat least in part on the first status code; generating are-initialization command for the failing kiosk device; and transmittingthe re-initialization command to the failing kiosk device.